Reactive applications relate to a class of applications that are event-driven and configured to operate upon detection of events. The exact timing and content of such events are not usually known in advance. Many tools in different areas have been built to detect events, and to couple their detection with appropriate actions. These tools exist in products that implement active databases, event management systems, the “publish/subscribe” mechanism, real-time systems and similar products.
U.S. Pat. No. 6,604,093 (Etzion et al.) issued Aug. 5, 2003 and entitled “Situation awareness system” is incorporated herein by reference and discloses a configurable event driven rules-based system for processing events in sequential order. Throughout the remainder of this document, this system will be referred to by its acronym “AMIT” meaning “Active Middleware Technology.” AMIT is a trademark of International Business Machines Inc. of Armonk, N.Y., USA. That is, incoming events are processed one by one, while all relations (both temporal and quantitative) among different events' instances are kept in memory. While this approach is absolutely necessary for the case, where most of the events have temporal relations (e.g. a specific event's sequence occurs within some specified period of time), it will be not scalable for other cases, where a huge number of temporally independent events should be processed in the distributed environment (e.g. aggregation event rules, where the order of single event instances are less important then their calculated statistical metrics). Also, if AMIT event rules (event combinations) include database queries, then the ACID transaction support should be added.
U.S. Pat. No. 6,272,515 (Fouquet) issued Aug. 7, 2001 and entitled “Method of scheduling distributed transactions” is incorporated herein by reference and discloses a method of scheduling distributed transactions for a transactional monitor with the possibility of parallel initiation of transactions in order to serialize activation of the operations of the transactions in accordance with the chronological order in which the transactions are initiated and allowing for conflicts of execution among operations of different transactions or of the same transaction. Thus, while such method is applicable to conventional transactions that can be divided into elementary operations and events signal only a transaction initiation or an operation termination, such an approach is not suitable for those rule engines that detect pre-defined events combinations (event driven rules) for subsequent processing in distributed transaction environments.
In such case, an event driven rule engine handles every event instance as an atomic transaction that cannot be further divided to composite operations. Such a transaction should lock a resource that is specific for the handled event instance. The resource is a data structure that represents a computational window, which is a time period, where the event instance can be accounted and where a predefined event's combination (rule) can occur. In case of temporal and other semantic dependencies among incoming events, there are possible conflicts among different distributed transactions that should be resolved.